Many computing environments, especially those found in corporate or governmental organizations, include host applications running on mainframe systems, for example, IBM's z/OS operating system. These organizations often rely on mainframe host applications to run critical applications and bulk data processing, and often maintain teams of host application developers who specialize in writing programs for these platforms. Common mainframe host applications can be run in either batch or online mode, and are written in languages such as COBOL, PL/I, C/C++, Assembler, Java, CLIST, REXX, or others such as DB/2 stored procedures.
Increasingly, computing environments of all types seek to utilize resources or services made available according to the service-oriented architecture (SOA) model. The SOA model is a software design and software architecture design pattern based upon discrete pieces of software providing application functionality as services to other applications. These services are sometimes provided over a network, thus facilitating the cooperation of computers and applications with network access. According to the web service SOA model, every computer in the network can run an arbitrary number of web services, and each web service may be built in a way that ensures that the service can exchange information with any other service in the network. If an SOA model is implemented over standard internet protocols, it is often termed a web service. Web service providers and clients communicate according to open protocols, sometimes termed service standards or web service specifications, which allow them to be used independently of platforms and programming languages, and without human intervention. Examples of common protocols include Representational State Transfer (REST), Simple Object Access Protocol (SOAP), JavaScript Object Notation Web-Service Protocol (JSON-WSP), Extensible Markup Language (XML) and others. The web services are defined by a Web Services Description Language (WSDL), an XML-based interface description language that is used for describing the functionality offered by a web service. The WSDL describes services as collections of network endpoints or ports. The WSDL specifications provide an XML format for documents for this purpose (called a WSDL file) wherein the abstract definitions of ports and messages are separated from their concrete use or instance. To be a web service client, an application must be capable of performing certain tasks required by the nature of internet communications and the web service protocols, including, for example, native sockets programming, string manipulation, and XML parsing.
Increasingly, existing host programs seek access to information that is best accessed via, or possibly only accessible via, SOA services. Adapting existing host programs to use SOA services presents several difficulties. The host programs are often maintained by developers or teams of developers with traditional host developer skillsets. These host developers are likely to encounter a variety of difficulties in adapting host programs to use SOA services because of a mismatch between the common types of problems and architecture between the two environments. Unlike in host systems, SOA services no longer entail one discrete program natively or dynamically “calling” another program. Instead, the target service in an SOA service is always on another computer. There is always a network and a network communication involved in SOA web services. There are likely to be multiple environments in SOA services such as a production environment and multiple test environments. SOA services may exist on multiple execution domains, or the same target service may even exist multiple times in the same execution domain. Host developers are likely to encounter difficulties in view of the foregoing challenges when trying to route SOA requests to the correct instance of a target service. To do so successfully would require these developers to have a substantial knowledge of the network naming conventions, to keep up with changes to target services in multiple test environments, and to imbed infrastructure logic in their host applications, which may be undesirable generally because it introduces a lack of portability into the applications and diminishes their robustness.
Adapting host programs to use SOA services also implicates a variety of security issues. When invoking SOA services, it is preferable not to pass user credentials, but rather to secure target services using ProcessID credentials. Requester credentials may be authenticated by a Resource Access Control Facility (RACF), and target service ProcessID credentials may be authenticated according to the Lightweight Directory Access Protocol (LDAP) using Basic Authorization Credentials (BAC) in the HTTP request header. Further tangling the security is that different instances of the same target service are likely to have separate credentials, and those credentials may change over time. These security and authorization safeguards introduce an additional level of complexity to the host application that is often difficult to manage in an organized, disciplined, and efficient fashion.
Even under optimistic assumptions of developer skill and dedication to the task, training these programmers to develop the necessary skills is expensive and time-consuming. To do so would likely require a large degree of trial-and-error development as the host application teams experiment with the SOA web services and interfaces to achieve an acceptable level of service. This approach may involve an unacceptably high risk of complete failures in the event the developers are unable to master the requisite skills and successfully incorporate the SOA services into the host application. If there are multiple host development teams, as is common in large enterprise or corporate environments, then it is likely that these teams would incur a large degree of duplication of effort, and ultimately arrive at multiple one-off solutions unique to each team and incompatible with one another.
Even if host developer teams are able to incorporate SOA web client functionality into their applications, the APIs commonly available to host applications to enable SOA client access have several drawbacks, if they are even available at all, and are thus ill-suited for this purpose. Batch jobs and DB2 stored procedures, two common environments in which host applications execute, have no high level APIs suitable for SOA client communications. Other host application environments such as CICS or IMS have the WEBSERVICE interface and the ICAL interface using IMS Connect and IMS Soap Gateway, respectively, but use of these APIs is limited to the corresponding execution environment The only common API across all execution environments is native sockets programming, which is complicated, and requires networking protocols that are difficult to learn, and string manipulation and XML programming in host applications. This is not a common skill among host programmers.
All of these issues are problematic when encountered by traditional host developers. Moreover, even if an organization does successfully implement SOA client code in its host programs, it will experience low code reusability, slow development, and error-prone host applications that must be addressed by programmers familiar with that particular host application. Overall, this approach presents a development environment that is far from ideal for the incorporation of SOA web services into host applications.